Any discussion of the prior art throughout the specification should in no way be considered as an admission that such prior art is widely known or forms part of common general knowledge in the field.
It is known to use a large number of access control devices in an access control environment. It is also known for such an environment to include:                Connected access control devices, which are connected to a network and communicate with a central administration server over that network.        Disconnected access control devices, which are not connected to the network. For example, in some cases an access control device, due to its location, cannot be provided with a network connection (either wired or wireless).        
Typically, there is a need to periodically provide modified configuration data to access control devices. This is a relatively straightforward process in the case of a connected access control device—the modified configuration data is delivered by the administration server to the device over the network. However, providing modified configuration data to disconnected access control devices presents practical difficulties. One option is to transport the disconnected device to a location where it can receive the configuration data from a computational device, or where it can access an available network connection. However, in many instances, the device is not easily transportable.
As such, a more appropriate technique is to transport a portable manual update device to the disconnected access control device. Manual update devices may include the likes of portable computers (including cell phones and PDAs), smartcards, USB drives, and the like.
Similar problems present themselves in other environments where a plurality of disconnected devices (such a parking meters and the like) need to be configured for operation as a collective, although there is no available common network connection. For the present purposes, such disconnected devices are referred to as “disconnected remote devices”.
Traditionally, applying configuration data to disconnected remote devices via manual update devices has involved “blindly” applying whatever data is stored on those manual update devices to the disconnected remote devices. When there are many such manual update devices (for example ten users with ten different update devices) and only some percentage of these have the most current configuration, it becomes unreliable to know what data has been applied to the disconnected remote devices. Consider scenarios where, for instance, an administrator decides to change the parking rate at a number of parking meters. On Monday user X starts applying this to the meters as he moves around on foot, and later that week user Y also goes past these meters (but with a different manual update device). If user X and user Y do not carry the same information on their manual update devices, the master system has no way of knowing what has been applied. Traditionally this has been solved by manual processes that force each manual update device to carry the same information, which are obviously error prone. Furthermore, such a solution does not scale readily.
These concerns are not limited to disconnected access control devices; they apply to disconnected remote device generally, being devices that operate as a collective within the context of a host system, although they are not in communication with that host system.
It follows that there is a need in the art for improved systems and methods for managing configuration data in disconnected remote devices.